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rowe@cs.nps.navy.mil 

1.  Introduction 

The  Metutor  system  is  a  set  of  software  engineering  tools  to  enable  instructors  not  especially 
knowledgeable  about  computers  to  implement  intelligent  computerized  tutors.  The  tutors  constructed 
are  for  skills  requiring  the  sequential  application  of  actions.  The  tools  are  contained  at  NPS  in  the 
directory  ~rowe/proAnetutor,  and  the  main  files  are: 

--metutor27  etc:  the  core  problem-independent  code,  written  Quintus  Prolog: 

--■efire,  the  original  demonstration  application  for  firefighting,  which  can  be  run  either  with  or 
without  graphics: 

--megrapb27  etc:  the  problem-independent  graphics  interface  for  the  student,  written  in  Quintus 
Prolog  using  the  Prowindows  X windows  interface:  this  is  loaded  automatically  when  the  program 
is  started  with  grapbiesflag  asserted; 

--drawpatb,  a  program  that  helps  the  instructor  construct  line  drawings  with  the  mouse,  and  save 
them  as  bitmaps  (this  runs  under  Prowindows). 

The  directory  also  contain  other  applications  that  students  have  written,  most  notably: 

-kangfuel.  a  aircraft  emergency  procedure  tutor,  which  also  has  graphics: 

-galvinbostage,  a  hostage-crisis  management  tutor. 

-seemscuba,  a  scuba  procedure  tutor. 

All  these  files  should  be  unprotected:  feel  free  to  explore  them.  Other  example  applications,  less 
thoroughly  tested,  also  exist,  including  tutors  for  (1)  replenishment  at  sea.  (2)  cardio-pulmonary  resusci¬ 
tation.  and  (3)  use  of  an  electronic  mail  tool. 

The  firefighting  tutor  is  the  best  example  tutor  to  study  because  it  is  well-debugged,  has  a  nice  graphics 
interface,  and  contains  most  of  the  ideas  mentioned  below.  To  run  it,  do  cd  "  rowe/pro/metutor  to 
Unix,  then  prolog.  then  [metutor27,mefire]t  go.  (note  the  necessary  period  at  the  end). 

We  discuss  now  the  necessary  problem-dependent  information  that  an  instructor  must  specify  to  build  a 
new  tutor  application.  This  will  go  in  a  separate  file,  like  mefiure,  that  will  be  loaded  together  with  a 
metutor  file  to  create  the  tutor. 

2.  Fact  and  operator  representation 

The  problem  definition  that  a  teacher  supplies  must  follow  strict  formats  compatible  with  Prolog  data. 
That  means  facts  and  actions  ("operators'')  must  be  in  first-order  predicate  calculus  notation.  This  nota¬ 
tion  consists  either  of  a  single  word  or  a  word  followed  by  a  left  parenthesis,  some  arguments,  then  a 
right  parenthesis.  Multiple  arguments  must  be  separated  by  commas. 

Example  operator  representations  are  "yell",  "test(oxygen)"  meaning  to  test  the  oxygen,  and 
‘test(oxygen.tester)’  meaning  to  test  the  oxygen  tester.  Generally  the  first  word  should  be  a  verb,  and 
any  remaining  words  should  constitute  (when  taken  in  order)  the  rest  of  a  phrase  describing  the  operator 
more  precisely:  otherwise  the  English  paraphrase  may  sound  funny. 

Example  fact  representations  ate  "smokey"  meaning  there  is  much  smoke  present,  "open(door)"  mean¬ 
ing  the  door  is  open,  and  "inside(firemanxompartment)"  meaning  the  fireman  is  inside  the  compartment. 
Generally  with  arguments,  the  word  in  front  of  them  should  be  a  property  or  relationship  name. 


precoodition(extinguisb,[locatioti(fire),raging(fire),equipped(team), 

set(boundaries),confrooted(fire)]). 

This  says  chat  in  order  to  extinguish  a  fire,  your  location  must  be  at  the  fire,  the  fire  must  be  raging,  the 
fire  team  must  be  equipped,  the  boundaries  of  the  fire  must  be  set,  and  you  must  be  facing  the  fire. 

In  the  three-argument  form,  the  additional  argument  is  the  second,  the  context  (list  of  facts  which  must 
be  present  in  the  current  state)  for  the  precondition  facts  to  apply.  The  difference  between  the  first  and 
second  arguments  is  that  the  first  represents  subgoals  that  must  be  achieved  if  not  already  true,  whereas 
the  second  argument  represents  facts  that  are  just  checked  without  any  attempt  to  achieve  them.  The 
three-argument  form  is  useful  when  two  or  more  operators  can  achieve  the  same  goal  facts,  and  the  best 
choice  depends  on  the  current  state. 

As  with  recommendation  conditions,  the  three-argument  forms  have  priority  over  the  two-argument 
forms.  Also  note  that  a  precondition  assertion  must  be  given  for  every  operator  in  the  problem;  if  there 
no  preconditions  on  application  an  operator,  it  should  have  the  empty  list  (0)  as  its  precondition  list. 

Precondition  facts  can  also  be  negative,  meaning  they  must  be  false  before  an  operator  can  be  applied. 
Again,  use  the  not  construct  Such  preconditions  succeed  if  the  indicated  fact  is  absent  in  the  state  to 
which  you  want  to  apply  the  operator.  But  not  facts  will  never  appear  in  state  descriptions,  since  the 
absence  of  a  fact  is  equivalent  to  the  assertion  of  the  negative  of  that  fact. 

Metutor  is  intended  for  applications  that  present  significant  numbers  of  feasible  alternative  approaches 
to  the  student  (else  a  simpler  tool  is  appropriate).  Thus,  the  instructor  is  cautioned  not  overspecify 
preconditions  so  that  the  student  is  confined  to  only  a  narrow  corridor  of  possible  operator  sequences. 
Instead,  the  student  should  be  allowed  to  see  the  consequences  of  their  suboptimal  operators.  For 
instance,  if  a  firefighting  student  forgets  to  equip  their  fire  team,  the  team  members  should  get  burnt 
when  they  try  to  extinguish  the  fire;  this  is  more  educational  than  putting  an  extra  precondition  on 
"extinguish"  of  "equipped(team)".  In  general,  preconditions  should  be  either  logically  necessary  condi¬ 
tions  (like  you  cannot  put  out  a  fire  unless  the  fire  is  still  burning)  or  critical  requirements  of  the  appli¬ 
cation. 


5.  Postconditions 

Postconditions  represents  the  consequences  of  an  operator.  There  two  kinds,  facts  that  are  false  (if  they 
ever  were)  after  an  operator  is  applied,  "deletepostconditions",  and  facts  that  are  true  (if  they  were  not 
already)  after  the  operator  is  applied,  "addpostconditions”.  The  deletepostconditions  are  removed  first, 
then  the  addpostconditions  are  added.  Postconditions  should  represent  direct  consequences  of  the  opera¬ 
tor. 


The  predicate  names  used  are  deletepostcoodition  and  addpostcondition.  They  have  two-argument, 
three-argument,  and  four-argument  forms.  In  the  two-argument  form,  the  first  argument  is  operator 
name  and  second  argument  is  the  list  of  postconditions.  In  the  three-argument  form,  the  added  middle  a  For 
argument  is  a  context  like  with  three-argument  recommendations  and  preconditions.  The  four-argument 
form  is  like  the  three-argument  form  except  that  its  last  argument  is  a  message  string,  enclosed  in  apos¬ 
trophes.  which  will  be  printed  out  for  the  student  when  the  postconditions  are  applied;  this  is  useful  for  ,ed 
unusual  postconditions.  Here  are  some  examples:  t  u  a*loa_ 
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detetepostcoodition(extinguish,[raging(fire),tested(gases),tested(oxygen), 
verified(out(fire)),watch«d(refiashittg),debriefed(teaiD),set(boundaries), 
safe(gases),safe(oxygeD),iinsare(gases)>unsafe<oxygen),coBfroated(fire)]). 
addpostcooditioo(extin  guish,(out(firt), watery  .smokey]). 
addpostcoodition(extinguisb,{not(deenergized(fire,arfa))], 

{presen  t(casualty),dead(casualty),present(cra  ter  ),raging(fire)], 

’There  b  a  big  explosion!’). 

The  first  definition  gives  aU  the  things  that  become  false,  if  not  already,  when  a  fire  is  extinguished: 
that  it  is  raging,  that  oxygen  and  other  gases  are  tested  or  safe  or  unsafe,  that  the  fire  is  verified  to  be 
out,  that  reflashing  of  the  fire  is  being  watched,  that  the  fire  team  is  debriefed,  that  the  boundaries  are 
set,  and  that  the  fire  is  confronted.  The  second  definition  gives  the  things  that  usually  become  true  in 
the  same  situation:  that  the  fire  is  out,  that  the  area  is  watery,  and  that  the  area  is  smokey.  The  last 
definition  gives  the  things  that  become  true  in  the  special  case  in  which  the  student  tries  to  extinguish 
when  the  power  to  the  fire  area  is  not  off:  that  a  casualty  is  present  and  dead,  that  a  crater  in  the  floor 
is  present,  and  that  the  fire  is  raging.  Also,  when  the  special  case  for  the  third  rule  occurs,  the  message 
"There  is  a  big  explosion!"  is  printed  out. 

Four-argument  forms  have  priority  over  three-argument  forms,  and  three-argument  forms  have  priority 
over  two-argument  forms.  This  means  special  cases  have  priority  over  defaults. 

The  first  argument  to  all  these  postcondition  forms  may  also  be  a  list  of  operators  instead  of  a  single 
operator.  Then  the  postconditions  apply  to  all  operators  in  that  list  Note  also  there  cannot  be  negative 
postconditions. 

6.  Random  changes  to  states 

One  of  the  must  important  features  of  the  Metutor  system  is  ability  to  specify  random  changes  to  states. 
Such  changes  can  suggest  the  indeterminacy  of  the  real  world,  as  well  as  unforeseen  complications  that 
can  arise.  For  instance  in  firefighting,  the  fire  may  refuse  to  go  out  after  one  attempt  at  extinguishing 
it,  or  a  member  of  the  fire  team  may  get  injured,  or  someone  may  accidentally  turn  the  power  back  on. 

Such  events  can  be  specified  by  randebange  facts  of  five  or  six  arguments.  The  only  difference 
between  the  five-argument  and  the  six-argument  forms  is  in  an  optional  sixth  argument,  a  message  that 
can  be  printed  out  when  the  random  change  is  performed.  The  first  argument  is  the  operator  name,  the 
second  is  the  context,  the  third  is  a  list  of  facts  that  will  be  deleted  (if  present)  by  the  random  change, 
the  fourth  is  list  of  facts  that  will  be  added  (if  not  present)  by  the  random  change,  and  the  fifth  argu¬ 
ment  is  the  change  probability  (its  relative  frequency).  For  example: 

randchange(extinguish,[],out(fire),raging(fire), 0.3, 'Fire  is  still  raging.’). 

This  says  that  30%  of  the  time  when  a  student  tries  to  extinguish  a  fire,  the  fire  will  continue  raging. 

Each  random  change  that  can  apply  to  given  state  will  be  applied  independently,  with  independent  pro¬ 
babilities.  However,  if  more  than  one  random  change  is  applied,  the  second  change  will  operate  on  the 
state  resulting  from  the  first  change.  Random  changes  are  done  after  the  postconditions  are  computed. 

Randchange  facts  can  refer  to  a  special  action  "init";  such  changes  will  be  applied  to  the  start  state,  to 
derive  the  first  state  in  which  the  student  must  choose  an  action. 

As  with  postconditions,  the  first  argument  may  also  be  a  list  of  operators,  in  which  case  the  random 
changes  apply  to  any  operators  from  that  list. 


7.  Initialization 
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Initialization  of  the  tutor  for  application  requires  three  one-argument  predicates.  The  intro  predicate 
takes  one  argument,  a  string  which  printed  out  at  the  start  of  the  session  to  the  students.  The 
startstate  predicate  specifies  the  starting  state,  and  goal  specifies  the  top-level  partial  goal  description. 
The  latter  is  partial  only  in  the  sense  that  you  need  not  specify  ail  the  facts  that  will  be  true  when  a 
goal  slate  is  achieved,  only  die  essential  facts. 

For  example,  our  firefighting  tutor  has  these  specifications: 

intro(*You  are  the  fire  team  leader  on  a  IJ.S.  Navy  ship;  a  fire  is  reported.’). 
start_state({iocation(repair, locker  )^aging(fire)^mokey]). 
goal(Iverified(out(fire))4afe<gases)4afe(oxygen),not(equipped(team)), 
not(smokey)4K>t(watery),not(watcbed(reflashing))^ot(present(casualty)), 
aot(unreplaced(casualty)),not(treated(casualty)),iiot(dead(casualty)), 
debnefed(team),deenergized(fire,area)]). 

8.  Associating  bitmaps  with  facts 

If  the  fact  graphicsflag  of  no  arguments  is  included  somewhere  in  the  problem-defining  file,  the  Prolog 
compiler  will  try  to  display  bitmap  graphics  for  facts  in  the  cunem  state  that  have  associated  bitmaps. 
Such  associations  are  specified  with  the  bmap  predicate  of  five  or  six  arguments.  The  first  argument  is 
a  fact,  the  second  is  a  context  under  which  this  bitmap  should  be  displayed,  the  third  is  the  name  of  the 
file  containing  the  bitmap  to  be  loaded,  the  fourth  is  the  X-coordinate  of  where  the  upper  left  comer  of 
the  bitmap  should  go  on  the  screen,  and  the  fifth  is  the  Y-coordinate  of  the  upper  left  comer.  For 
instance: 


bmap(raging(fire),  (location(fire)],  firc2,308,135). 

This  says  that  if  the  fire  is  raging  and  the  fire  team  is  located  at  the  fire,  the  screen  should  show  flames 
(whose  bitmap  is  in  file  "fire2")  with  upper  left  comer  of  the  bitmap  at  (308.135).  Dimensions 
represent  integer  numbers  of  pixels,  which  on  a  Sun  terminal  are  approximately  0.2  mm.  Coordinates 
are  measured  from  left  to  right  for  the  X-coordinate  and  top  to  bottom  for  the  Y-coordinate. 

An  optional  sixth  argument  to  bmap  is  the  color  associated  with  the  bitmap,  which  is  only  used  on  a 
color  terminal,  determined  automatically  by  querying  your  terminal.  The  color  argument  must  be  one 
of  white,  black,  gray,  red,  blue,  green,  yellow,  purple,  and  cyan  (do  not  quote  the  color  name). 

Since  color  graphics  do  not  print  well  in  a  screen  dump  with  the  "xwd"  command  of  XWindows. 
include  the  zero-argument  nocolorflag  in  your  file  to  prevent  it  from  using  color  on  a  color  terminal  if 
you  want  to  do  screen  dumps.  To  be  able  to  do  a  screen  dump  just  by  typing  "printscreen"  and  left- 
clicking  the  mouse  in  a  background  area  of  your  screen,  include  this  line  in  your  ".cshrc"  file: 

alias  printscreen  ’xwd  I  xpr  -device  ps !  Ipr  -Pps’ 


You  can  have  more  than  one  shape  shown  for  the  same  fact,  if  you  place  them  far  enough  apart  on  the 
screen.  Shapes  are  stored  as  rectangular  bitmaps;  whenever  two  such  rectangles  overlap  on  the  screen, 
the  colored  areas  of  both  are  intermingled  by  default,  with  the  color  chosen  randomly  when  two 
different  colors  appear  at  the  same  place  on  the  screen  for  the  two  rectangles.  If  you  prefer  instead  that 
certain  shapes  occlude  others,  include  facts  of  predicate  name  draw_order  to  say  the  first-argument  bit¬ 
map  file  should  be  drawn  before  the  second.  For  instance: 

draw _ord*r(fire  1  .team  1 ). 

says  that  the  bitmap  in  file  "teaml"  should  be  drawn  over  bitmap  in  "firel".  Text  (see  below)  cannot 
be  made  to  occlude  unless  you  put  it  a  bitmap. 

The  bitmap  file  necessary  should  be  in  Postscript  black/white  form,  even  if  it  is  to  be  drawn  in  a  color. 
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Two  utilities,  the  simple  drawpatb  and  the  more  elaborate  drawgrapb.  can  be  used  to  create  simple 
line  drawings  and  shapes  and  put  them  in  bitmaps.  These  files  are  in  'rowe/pro/pw;  start  Prowindows, 
and  them  load  them  by  (’*  rowe/p  ro/pw/drawpath’].  or  [’'rowe/pro/pw/drawgraph’).  (note  the 
periods  at  the  end). 

Some  facts  are  better  represented  by  text  labels  in  the  drawing  pan  of  the  screen,  or  maybe  text  is 
appropriate  in  addition  to  a  shape,  like  labels  on  a  picture  of  switch.  If  so,  and  black  non-occluding 
labels  are  sufficient,  use  text  facts  of  five  arguments  like  bmap  facts  but  where  the  third  argument  is 
the  text  string  to  display  rather  than  a  file  to  load.  Text  is  always  displayed  in  black.  You  can  display 
several  texts  at  different  places  for  the  same  fact 

9.  Nonverbal  action  selection 

Besides  clicking  on  the  menu  items,  you  can  define  left-clicks  within  the  picture  area  to  select  opera¬ 
tors.  For  instance,  if  you  have  a  picture  of  vertical  switch  in  the  picture,  left-clicking  near  the  top  of  it 
can  turn  the  switch  up.  To  implement  this,  you  must  specify  the  coordinates  of  a  rectangular  area 
within  the  picture  wherein  a  click  means  a  given  operator  name.  Predicate  opdick  needs  the  coordi¬ 
nates  of  the  upper  left  comer  first,  then  the  x-width  and  y-height,  then  the  context,  then  the  operator 
name.  For  example: 

opc!ick(200,20t20,50,(visible(switch,power)],tun>(power,on)). 

says  that  whenever  the  student  clicks  the  left  mouse  button  within  the  area  20  pixels  wide  and  SO  pixels 
high  with  upper-left  comer  (200,20),  and  whenever  the  power  switch  is  then  visible,  it  means  that  the 
student  is  choosing  the  operator  "turn  power  on". 

10.  Debugging  flags 

Two  flags,  debugflag  and  studentflag.  help  debug  programs.  The  first  helps  debug  the  instructor's 
recommended,  precondition,  deletepostcondition.  and  addpostcondition  definitions.  When  debugflag 
is  asserted  (by  assert(debugflag).).  the  program  will  print  out  exhaustive  information  about  all  the 
hypothetical  reasoning  that  it  does. 

The  debugflag  printout  uses  level  numbers,  which  refer  to  depth  in  the  means-ends  problem- 
decomposition  tree,  counting  the  root  problem  as  level  1.  The  printout  is  sufficient  for  you  to  build  a 
complete  means-ends  tree  if  you  need  to  figure  out  more  precisely  what  the  hypothetical  reasoning  is 
doing.  The  "Unsolvable  problem”  message  is  the  most  common  indication  of  a  bug  (though  it  does  not 
always  mean  a  bug.  as  when  two  operators  are  recommended  for  a  situation  and  the  program  must 
backtrack  if  it  picks  the  wrong  one).  Its  first  occurrence  is  usually  the  most  significant,  because  one 
unsolvable  subproblem  can  make  problems  that  depend  upon  it  unsolvable  too.  It  suggests  a  missing 
recommendation  or  addpostcondition  for  an  operator,  or  an  unnecessary  precondition  or  deletepostcondi¬ 
tion.  The  operator  last  mentioned  when  the  unsolvable  problem  is  detected  is  often  the  operator  with 
the  bug. 

The  debugflag  also  causes  printout  of  other  diagnostic  information,  including  the  operator  that  the  tutor 
thinks  is  best  at  every  point,  and  for  a  graphics  program,  the  list  of  bitmaps  and  their  parameters  for  the 
current  screen  display.  The  program  caches  die  hypothetical  reasoning,  so  the  second  time  you  run  a 
problem  you  will  get  less  debugging  information,  with  indications  as  to  when  the  cache  is  invoked. 
Thus,  if  you  are  swamped  with  information  by  setting  the  debugflag  initially,  first  run  the  program 
awhile,  type  control-C  and  "a"  for  abort,  and  then  type  "go.”  again  to  restart. 

When  studentflag  is  asserted  (by  assert(studentflag).),  the  system  avoids  checking  the  instructor's  code 
for  a  number  of  common  careless  errors.  These  include  missing  definitions,  wrong  argument  types,  and 
some  spelling  errors.  This  checking  takes  time,  so  it  should  be  avoided  when  instructor  is  sure  their 
code  is  correct 
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11.  English  language  output 

The  system  also  prints  out  some  English  paraphrases  of  the  stales  encountered  and  objectives  desired. 
This  code  simply  assumes  that  words  ending  in  "s"  are  plural,  otherwise  singular.  If  this  not  true,  like 
for  "gas"  and  "sheep",  include  one-argument  facts  singular  or  plural  to  indicate  the  proper  forms. 

The  write  list  and  write  fact  routines  control  the  printout  of  English  paraphrases.  They  are  defined  by 
specifications  of  many  special  cases.  More  advanced  programmers  may  wish  to  modify  them  to  fine- 
tune  the  English  paraphrases  for  their  applications. 

12.  Example 

The  rest  of  this  paper  shows  the  full  definition  for  the  firefighting  tutor,  illustrating  most  of  the  features 
described  above.  We  also  show  some  screen  displays  produced  by  this  program. 
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r  Problem  definition  for  the  means -ends  firefighting  tutor  •/ 

intro)’You  are  die  fire  team  leader  on  a  U.S.  Navy  ship.  A  fire  has  been  reported.*). 

recommended)[treated(casuahy)],[],direct(medica],corpman)). 

recommended)[treated<casuaJty)].[],give)firsuud)). 

recommended(lnot(present(casualty))],Gjemove(casuahy)). 

recommended([not(unreplaced(  casual  ty))].Ojepiace(casuahy)). 

recommended)[out)fire)],(deenergized(fire,area)].extinguish). 

necommended((out(firc)],[not)deenergized(fire.area))].deenergize). 

recommended(lverified<out(fire))],[].verify(out)). 

r«commended)[deenergized)fire,area)].[].deenergize). 

recommended)[set)boundaries)],[],set)boundaries)). 

reconmiended)[confTonted)fire)],[deenergized(fire,area)].approach)fire)) 

recommended(lconfronied)fire)].(not(deenergized(fire,area))].deenergize). 

recommended)[waiched(reflashing)],[].set(reflash,  watch)). 

recommended)[safe)gases)].O.test(gases)). 

recommended)[ok(oxygen.tester)],[].iest(oxygen,tester)). 

recommended)[safe)oxygen)],[],test)oxygen)). 

recommended)(not)smokey)].[].desmoke). 

recommended(  [estimated(  water)) .(]  .estimate^ water) ) . 

recommended([not(  watery)), [), dewater). 

recotnmended((debriefed(team)],[],debrief). 
recommended)  (equipped)  team)]  ,Q  .equip). 
recommended([not(equipped(team))],0.store(equipmem)). 
recommended)  (not)  watched) reflashing))] , [(.secure) reflash  .watch)). 
recommended)[location)fire)].[equipped)  team  )].go( fire)). 
recommended)[location)fire)],[not(equipped(team))].equip). 
recommended)  (location)  re  pair  Jocker)] .( j,go)repair,locker)) . 
recommended)  (safe)  X)] ,[]  .wait). 

precondition)remove(casualty), 

(present)casualty),treated(casualty)jiot(dead(  casualty))]). 
precondition)direct)medical.corpman),[present(casuaity), 
present)  medic  ),not(angry(medic)),not(dead(casualty))]). 
precondition(give(firsuud).[present(casualty)jK>t(dead)casualty))]). 
precondiuon(replace(casualty).(unreplaced(casuaJty)]). 
precondiDon)equip,(location)repairJocker).not(equipped(team)))). 
precondition(<kenergize.[location(fire)]). 
precondition(set(boundaries),[location)fire),not(set(boundaries))]). 
precondition(approach(fire).[location(fire),not(confronted(fire)). 

raging(fire),set)boundaries), equipped)  team )] ). 
precondition<extinguish,[location)fire),raging(fire).equippe'^ieam), 
set(boundaries),confronted)fire),not)dead(casualty))]). 
precondition)set)reflash.watch),[not(watched(reflashing)). 

verified)  out)  fire)).safe(gases),safe(oxygen)]). 
precondition)verify(out). [location)  fire), out)  fire)]). 
precondition(test(oxygen,tester),[equipped(team)]). 
precondition)test(oxygen).  (ok)oxygen. tester) ,equipped(team ). 

not(unsafe)oxygen))j»ot(safe(oxygen))Jocation(fire)]). 
precondition)test  (gases), 

[equipped)  team)jiot(unsafe)gases))jiot)safe)gases))Jocaiion)fire)]). 
precondition^  smoke,[location)fire),out(fire),smokey]). 
precondition)estimate(water),[locaticm(fire),watery,out(fire)]). 
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precondition^ water .[location  (fire),  watery  .estimated)' water)]), 
precondition  store(equipment),[locanon(repair.kxker),equipped(ieam))) 
precondidon(debrief,{iocation(repairJocker)j)ot(equipped(teain)), 
watched(rcflashing)]). 

precondition(secive<refla&>  .alch),[watched(rtflashing),debriefed(team)]). 
prccoodiuon(go(firc).  1  anon<  repair  Jocker),not(dead(casualty))]). 
preconditions re pair  ,kicker),flocaUon(fire).not(dead(casuaJty))]). 
precondition wail.O). 

dele»epostcondition(remove(casuaJty), [present!  casualty  ).treated(casuajty)]). 
ta?’.uepostcondition(direct(medical,corpnum),[]). 
deletepostcondition(gi ve(firsutid),[] ). 
deletepostconditionreplace<casuaJty),[unreplaced(casuaJty)]). 
deletepostcondition(cquip,[(icbncfed(tcain)]). 

deJetepostcondition deenergize, [energized  jKM(smokey), test  ed(gases). 

iested(oxygen),debriefed(leam),verified(o<it(fire))]). 
deletepostcondition(set(boiindaries),[  tested!  gases).tested(oxygen), 
debriefed!  team),verified(out(  fire  )).confiron  ted! fire)]), 
deletepostcondi  tk>R(approach(fire),[iested!gases),iested(oxygen). 
debriefed(team),verified(out(fire))]). 

deletepostcondition(extinguish.[raging(fire),tested(gases).tested!oxygen), 
venfied!out(fire)).waiched(reflashing),debnefed(ieam),set(boundanes), 
safe(gases),safe(oxygen).unsafe(gases),iinsafe(oxygen),confronied(fire)]). 
deletepostcondi  tion!set!reflash.watch),0). 
deleteposlcondition(verify(out),[]). 
deletepostcondi  tion(test(gases),[unsafe(gases),safe!gases)]). 
deietqx>stconditiofl(test(oxy  gen.  tester), []  )• 

deletepostcondition(test(oxygen),[unsafe(oxygen).safe{oxygen)]). 
deletepostcondi  tion(desmoke, [smokey.de  briefed!  team).unsafe(gases). 

tested(gases),unsafe(oxygen).tested(oxygen)]). 
deletepostcondi  tion(estimate(water),[]). 

deletepostcondition(dewater,[  watery  xstimated(  water)  Jebriefed(team), 
tested(gases).unsafe(gases).tested(oxygen).unsafe(oxygen)]). 
deletepostcondition(store!equipmem).[equipped(teani)J). 
deletepostcondi  tion(debnef,D). 

deletepostcondition(secure(reflash.watch).|watched(reflashing))). 
deletepostcondi  tkm(go! fire), [location(repairjocker)]). 
deletepostcondition(go( repair  Jockcr),[kxaiion(fire)xonfronted(fire), 
tested(gases).tested(oxygen)]>. 

deletepostcondition(wait,[tested(gases),iested(oxygen).unsafe(gases). 

unsafe(oxygen)]). 

addpostcondition<remove(casualty).[unreplaced(  casualty)]). 
addpostcondition(direct(medical.corpman).[treated(casualty)]). 
addpostcondition(gi  ve(firstxid) .  [  treated(casuaJty )] ). 
addpostcondition(replace(casuaJty),D), 
addpostcondition(equip,[equipped(teain)]). 
addpostcondition!de  energize, [deenerg*  ^  jd(firexrea)xtnokey]). 
addjxwtcoC(dition<set(boundaries),[jet(bot*Kiaries)jmokey]). 
addpost  condi  tk>n!approach! fire), [confronted! fire),smokey]). 
addpostcondition(exttnguish.[out(fire),wateryjmokey]). 
»ddpostcondition<set(reflash,  watch). [watched(  reflashing)] ). 
«ddpostconditioi»(verify(out),[verified(out(fire))]). 
addpostcondition(test(gases).[tested(gases).safe(gases)]). 
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addpostcoi*dition(test(oxygen.tester).[ok(oxygen,iester)]). 
addpostcondition(lest(oxygen),[tested(oxygen).safe(oxygen)]). 
*ddposicoodjuon(dc  smoke. []). 
addpostcondilion(esdmaie(  water), (estimaled(waier)]). 
addposicondition(dewaier,0). 
addpostcondition(store<equipment).[]). 
addpostcondiuon(de  brief, (debnefed<  team)]). 

addpostcondition($ecure(reflash,watch),n). 

addpostcoiKbtion<go(fire),[localion(fire)]). 

addpostco«fction(go(repair,kx:ker),[locaiion(repair,locker)]). 

addpostcondition(wait,i]). 

deletepostcondilion(<teenergize,[not(equipped(team))],[tested(gases), 

iested(oxygen),verified(out(fire))]). 

deletepostcondition(debrief.[)ocation(fire)].[]). 

deletepostcondition(go<fire).(raging(fire)], 

[location(repairtkxker),tested(gases).tesied(oxygen), 

safe(gases),safe(oxygen)]). 

addpostcondition(deenergize,[not(equipped(team))],[present(casualty)]). 

addpostcondition(approach(fire),(not(equipped(team))]. 

[presenl(casualty).smokey]). 

addpostcondition(test(gases),[locaiion(fire).raging(fire)]. 

[tested(gases),unsafe(gases)]). 
addpostcondition(test(gases),nocation(repair  Joe  ker)  ] . 
(lested(gases)^afe(gases)]). 

addposlcondition(test(oxygen),(location(fire)xaging(fire)], 

[lested(oxygen).unsafe(oxygen)]). 

addpostcondition(iest(oxygen),llocation(repair.locker)]. 

[tested(oxygen).safe(oxygen)]). 
addpostcondition(give(  first  ,aid).[presem(medic)]. 

[treated(casualty).angry(medic)]). 

addpostcondition(extinguish,[not(deenergized(fire.area))]. 

[present(casualty),dead(casualty),present(crater).raging(fire)]. 

"There  is  a  big  explosion!'). 

addpostcondition(set(rcflash.watch).(smokey],[present(casualty)]. 

'The  reflash  waichpeison  was  overcome  by  the  smoke."). 
addpostcondition(set(reflash,watch).[unsafe(oxygen)],[present(casualty)]. 

"The  reflash  watchperson  collapsed.'). 
addpostcondition({go(repair,locker),go(fire),equip.deenergize, 

set(boundaries),approach(fire),extinguish,desmoke,estimaie(water), 
dewater,tcst(gases),test(oxygen,tester),test(oxygen), 
set(reflash,watch),storc(eqiiipment),de  brief ,secure(reflash ,  watc  h)] . 
[present(casualty)].[dead(casualty)],’Your  casualty  died!"). 

randchange(init,[].n.present(medic),0.5). 

randchangc([approach(fire),extinguish],0,[],present(casualty).0. 1 5. 

’A  team  member  got  burned."). 

randchange(extinguish,D.out(fire)jaging(fire).0.3,’Fire  is  still  raging.’). 
randchange({verify(out)4esmoke,dewaterjtore(equipment),de  brief]. 
{not(  verified(out(fire)))] . 

(out(fire).verified(out(fire)).debriefed(team),tested(gases), 
tested(oxygen),safe(gases),safe(oxygen),waiched(reflashing)J. 
[raging(fire)^mokey],0.3.’Unfortunate!y  the  fire  has  flared  up  again.’). 
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randchange<[verify(out),desmoke,(tewaterrstore(equipment),<fcbrief]. 

(verified(out(fire))],[out(fire),verified(out(fire)),debiiefed(team), 

tested<gases),tested(oxygen),safe(gases).safe(oxygen).watched(reflashing)]. 

[raging(fire),smokey],0.07,’Unfoitunately  the  fire  has  flared  up  again.*). 

randchange((desmoke,dewateTtexLnguish],deenergized(fire,area). 

deenergized(fire,area),[].0.08,’A  team  member  accidentally  turner  *he  power  on.' 
randchange([desmoke,dewater,store(equipment)].Q,U.present(casualty), 

0.08,’ A  team  member  got  injured.’)  :• 
randchange(test(gases),safe(gases).safe(gases),unsafe(gases).0.3. 

’The  gases  are  unsafe.’). 

randchange(test(oxygen).safe(oxygen).safe(oxygen),unsafe(oxygen).0.3. 

The  oxygen  is  unsafe.’). 

nopref(set(boundaries),deenergize). 

nopref(ltest(oxygen,tester),test(oxygen)],(test(gases)]). 

nopref([estimate(water).dewater],(desmoke]). 

nopref([estimate(water),dewater],[test(gases)]). 

nopref(desmoke,Uest(gases)]). 

f*  The  following  are  info  for  the  graphics  interface  */ 

bmap(location(repair,locker),[equipped(team)],equipped3.550.343.blue). 

bmap(location(repair,locker),[not(debriefed(team))]. 

Iocaiion_repair_locker,560,300,bl  ue). 
bmapdocation(fire), 

[equipped(team).not(confronted(fire)),not(present(casualty)), 
not(unreplaced(casualty))]. 
equipped3,550, 1 90,blue). 

bmapflocat  ion  (fire).  [equipped(team)jiot(confronted(fire)).present(casualty)]. 

equipped2,550,190.blue). 

bmap(location(fire). 

{equipped(team),not(confironted(fire)),unreplaced(casualty)], 
equipped2,550, 190,blue). 
bmap(location(fire). 

{ not  (equipped(  team  )).not(conffonted(  fire)),not(prese  nt(casualty )) . 

not(unreplaced(casualty ))] . 
unequipped!)  ,5 50, 1 90,blue). 
bmap(location(fire). 

[not(equipped(team)).not(confronted(fire)),present(casualty)], 

unequipped2.550,190,blue). 

bmapdocation(fire),  [not(equipped(team))jiot(confronted(fire)), 
unreplaced(casualty)]. 
unequipped2,550.190,blue). 
bmap(confronted(fire),[],confronted_fire,464,19,blue). 
bmap(raging(fire),  [location(repair,  locker)].  firel,2,158,red). 
bmap(raging(fire),  [location(fire)],  fire2,308,135jed). 
bmap(smokey,  [location(repair,  locker)],  smokey  1,8,1, yellow). 
bmap(smokey,  [location(fire)],  smokey2,380,6,yellow). 
bmap(watery,[],watery^73^72,green). 

bmap(present(medic),[not(angry(me(lic))4>ot(treated(casualty))], 
present_medical_corpman,775,170/ed). 
bmap(present(medic),[not(angry(medic)),treated(casualty)], 
present_medical_corpman,742,170jed). 
bmap(present(medic),langry(medic)],presentjnedical_coipm  an, 850,50  jed). 
bmap(present(casualty),[].present_casualty,651,188.blue). 
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bmap<  treat  ed(casualty ),[]  ,treated_casuaJty  ,639.236,blue). 
bmap(watched(reflashing),[],wau:hed_reflashing,330,90,blue). 
bmap<set(boundaries),[localjon<fire)].sei_boundaries,240 .227 .purple). 
bmap(venfied(out(fire)),[locaiion(firc)),verified_out_fire,316,163,purple). 
bmap(deenergized(fire,area),()ocatjon(fire)],deenergized_fire_area,  1 1 ,57). 
bmap(debriefed(team),[].debriefed_team,526.200,blue). 
bmap(ok(oxygen,tester),[]  ,ok_oxygen_tester,  100, 1 90, c  yan). 
bmap(tested(oxygen),[],tested_oxygen,89,266). 
bmap(tcsted(gases),D,tested_gases,  1 5,267). 
bmap(safe(oxygen),[]  ,safe_oxygen,88,24 3. purple) . 
bmap(safe(£ascs).n,safe_gases.3 1.242, purple). 
bmap(prescnt(crater),  (location(fire)],  smokey2, 100, 190, yellow). 
btnap(present(crater),  {location(fire)].  smokey2,5,  lOO.yeliow). 
bmap(present(crater),[],present_crater, 20,250). 
bmap(dead(casualty),[j,dead_casua]ty  ,665,190). 

text(estimaled(  water),!),"  100  gallons' ,330,285). 

opclick(273,272,230,61,llocation(fire).watery), dewater). 
opclick(380,6,320,175.Pocation(fire),smokey],desmoke). 
opclick(89.266,81,197,[Iocation(fire),unsafe(oxygen)).test(oxygen)). 
opclick(15,267,85,195,[location(fire),unsafe(gases)],test(gases)). 
opclick(775,170,55,125,[location(fire),present(medic).not(angry(medic))]. 
direct(medical,corpman)). 

draw_order(ok_oxygen_tester,tested_oxygen). 

draw_order(ok_oxygen_tester,safe_oxygen). 

draw_order(present_casualty,present_medical_corpman). 

draw_order(crealed_casualty,present_medical_coipman). 

start_state([location(repairJocker)jaging(fire)^mokeyj). 
goal([verified(out(firc))^afe(gases),safe(oxygen)jiot(equipped(team)), 
not(smokey),not(  watery)  jiot(watched(reflashing))jiot(present(casualty)), 
not(unreplaced(casualty)),not(treated(casualty)),not(dead(casualty)). 
debriefed(team),deenergized(fire3rca)]). 


12 


13 


TESTED  TESTED 


14 


TESTED  TESTED 


15 


UNCLASSIFIED 


Defense  Technical  Information  Center 
Cameron  Station 
Alexandria,  VA  22314 

Library,  Code  52 
Naval  Postgraduate  School 
Monterey,  CA  93943 

Center  fen-  Naval  Analyses 
2000  N.  Beauregard  Street 
Alexandria,  VA  22311 

Director  of  Research  Administration 
Code  08 

Naval  Postgraduate  School 
Monterey,  CA  93943 

Mr.  Russell  Davis 
HQ,  USACDEC 
Attention:  ATEC-1M 
Fort  Qrd,  CA  93941 

Dr.  Neil  C.  Rowe,  Code  CSRp 
Naval  Postgraduate  School 
Computer  Science  Department 
Monterey,  CA  93943 

Prof.  Ted  Lewis,  CS/Lt 
Naval  Postgraduate  School 
Computer  Science  Department 
Monterey,  CA  93943 


Distribution  List 


2 


2 


1 


1 


2 


50 


2 


16 


SECURITY  CLASSIFICATION  OF  THIS  PAGE 

UNCLASSIFIED 


